Conversation
…ments - Add Bitcoin-style block reward halving mechanism (50 coins, 210k interval) - Centralize all economic constants into bitcell-economics/src/constants.rs - Add flexible keypair management (--private-key, --key-file CLI args) - Implement battle visualization in wallet GUI with real RPC data - Add credit_account to StateManager for coinbase minting - Update blockchain to apply block rewards to proposers - Add comprehensive economic parameters (gas, timing, penalties, treasury) - Deprecate old params module for backward compatibility - Add RPC methods: bitcell_getTournamentState, bitcell_get_battle_replay - Improve tournament view with live data display All tests passing.
Co-authored-by: Steake <530040+Steake@users.noreply.github.com>
… logging Co-authored-by: Steake <530040+Steake@users.noreply.github.com>
- Add todo_now.md with comprehensive audit of unimplemented features - Add AGENT_PLAN.md with phased implementation workflow - Identify 4 critical blockers, 8 high priority, 6 medium priority items - Document 33 TODOs, 18 mock implementations, 2 panic calls - Provide structured plan for AI agent execution
- Add state() getter to Blockchain for RPC access - Implement eth_getBalance with real state queries - Parse hex addresses to PublicKey - Fetch balance from StateManager - Return hex-encoded balance - Implement eth_sendRawTransaction with full validation - Decode hex transaction data - Deserialize and validate transaction - Verify signature - Check nonce and balance - Add to transaction pool - Handle transaction pool errors properly Part of Phase 1 (Core Functionality) from AGENT_PLAN.md
- Add optional StorageManager backend to StateManager - Implement write-through caching for accounts and bonds - Add with_storage() constructor for persistent state - Add get_account_owned() and get_bond_owned() for storage fallback - Persist account and bond updates to RocksDB when available - Maintain in-memory cache for performance Part of Phase 1.4 from AGENT_PLAN.md Completes Phase 1: Core Functionality
There was a problem hiding this comment.
Pull request overview
This pull request introduces comprehensive wallet API functionality to the BitCell admin console and wallet GUI, enabling balance checks and transaction submission. It includes substantial RPC server implementation, WebSocket support, ZKP circuit improvements, network Gossipsub integration, VRF implementation, and detailed planning documentation for RC1 readiness. The changes span multiple core modules including node RPC, wallet GUI, state management, blockchain, and economics.
Key changes:
- Full JSON-RPC and WebSocket API implementation with Ethereum-compatible endpoints
- ZKP circuits upgraded from mock to real Groth16 proof generation/verification
- Wallet GUI enhanced with RPC client, QR code generation, and tournament visualization
- DHT/Gossipsub integration for decentralized block and transaction propagation
Reviewed changes
Copilot reviewed 38 out of 38 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
todo_now.md |
RC1 readiness audit documenting all unimplemented features and critical path |
AGENT_PLAN.md |
Step-by-step implementation plan for bringing BitCell to RC1 |
docs/RPC_API_Spec*.md |
Comprehensive RPC and API specifications for node interfaces |
crates/bitcell-zkp/src/*.rs |
Upgraded ZKP circuits from mocks to real Groth16 implementations |
crates/bitcell-wallet-gui/src/*.rs |
Added RPC client, async support, QR codes, and tournament visualization |
crates/bitcell-node/src/rpc.rs |
Complete JSON-RPC server with eth_* and bitcell_* methods |
crates/bitcell-node/src/ws.rs |
WebSocket endpoints for real-time battle and block updates |
crates/bitcell-node/src/dht.rs |
Gossipsub integration for P2P message propagation |
crates/bitcell-node/src/blockchain.rs |
VRF implementation and block reward crediting |
crates/bitcell-state/src/lib.rs |
Storage backend integration with persistence support |
crates/bitcell-economics/src/*.rs |
Consolidated economic constants and updated reward calculations |
crates/bitcell-admin/src/api/wallet.rs |
New wallet API endpoints for balance and transaction operations |
check_output.txt |
Compilation errors and warnings from build check |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
+74
to
+108
| error[E0277]: the trait bound `Hash256: LowerHex` is not satisfied | ||
| --> crates/bitcell-node/src/rpc.rs:195:39 | ||
| | | ||
| 195 | let mock_hash = format!("0x{:x}", bitcell_crypto::Hash256::hash(tx_data.as_bytes())); | ||
| | ---- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `LowerHex` is not implemented for `Hash256` | ||
| | | | ||
| | required by this formatting parameter | ||
| | | ||
| = help: the following other types implement trait `LowerHex`: | ||
| &T | ||
| &mut T | ||
| BytesMut | ||
| NonZero<T> | ||
| Saturating<T> | ||
| Wrapping<T> | ||
| axum::body::Bytes | ||
| base16ct::display::HexDisplay<'_> | ||
| and 42 others | ||
| = note: this error originates in the macro `$crate::__export::format_args` which comes from the expansion of the macro `format` (in Nightly builds, run with -Z macro-backtrace for more info) | ||
|
|
||
| error[E0308]: mismatched types | ||
| --> crates/bitcell-node/src/rpc.rs:399:58 | ||
| | | ||
| 399 | let miner_pk = bitcell_crypto::PublicKey::from_bytes(&miner_bytes).map_err(|_| JsonRpcError { | ||
| | ------------------------------------- ^^^^^^^^^^^^ expected `[u8; 33]`, found `&Vec<u8>` | ||
| | | | ||
| | arguments to this function are incorrect | ||
| | | ||
| = note: expected array `[u8; 33]` | ||
| found reference `&Vec<u8>` | ||
| note: associated function defined here | ||
| --> /Users/oli/code/BitCell/crates/bitcell-crypto/src/signature.rs:38:12 | ||
| | | ||
| 38 | pub fn from_bytes(bytes: [u8; 33]) -> Result<Self> { | ||
| | ^^^^^^^^^^ |
There was a problem hiding this comment.
The code has compilation errors that need to be fixed:
- Line 195:
Hash256doesn't implementLowerHextrait - usehex::encode(hash.as_bytes())instead offormat!("0x{:x}", hash) - Line 399: Type mismatch -
PublicKey::from_bytes()expects[u8; 33]but receives&Vec<u8>- useminer_bytes_arrinstead of&miner_bytes
| } | ||
|
|
||
| let buffer = SharedPixelBuffer::<Rgba8Pixel>::clone_from_slice( | ||
| unsafe { std::slice::from_raw_parts(pixels.as_ptr() as *const u8, pixels.len() * 4) }, |
There was a problem hiding this comment.
Unsafe code used without justification. The slice::from_raw_parts call should be replaced with safe Rust alternatives. Use SharedPixelBuffer::clone_from_slice with the pixel vector directly converted to bytes safely, or use the proper Slint API for image creation.
Suggested change
| unsafe { std::slice::from_raw_parts(pixels.as_ptr() as *const u8, pixels.len() * 4) }, | |
| &pixels, |
Comment on lines
+39
to
+40
| let buffer = SharedPixelBuffer::<Rgba8Pixel>::clone_from_slice( | ||
| unsafe { std::slice::from_raw_parts(pixels.as_ptr() as *const u8, pixels.len() * 4) }, |
There was a problem hiding this comment.
Same unsafe code issue - using slice::from_raw_parts without justification. Convert the pixel buffer to bytes safely or use proper Slint image creation APIs.
Suggested change
| let buffer = SharedPixelBuffer::<Rgba8Pixel>::clone_from_slice( | |
| unsafe { std::slice::from_raw_parts(pixels.as_ptr() as *const u8, pixels.len() * 4) }, | |
| let buffer = SharedPixelBuffer::<Rgba8Pixel>::from_vec( | |
| pixels, |
|
|
||
| .route("/api/blocks", get(api::blocks::list_blocks)) | ||
| .route("/api/blocks/:height", get(api::blocks::get_block)) | ||
| .route("/api/blocks/:height", get(api::blocks::get_block)) |
There was a problem hiding this comment.
Duplicate route registration for /api/blocks/:height. Line 117 is identical to line 116, which will cause a routing conflict.
Suggested change
| .route("/api/blocks/:height", get(api::blocks::get_block)) |
…rved Co-authored-by: Steake <530040+Steake@users.noreply.github.com>
…add tests Co-authored-by: Steake <530040+Steake@users.noreply.github.com>
…, tx index, and ZKP circuits Co-authored-by: Steake <530040+Steake@users.noreply.github.com>
…overy Co-authored-by: Steake <530040+Steake@users.noreply.github.com>
…cation Co-authored-by: Steake <530040+Steake@users.noreply.github.com>
…xposure Co-authored-by: Steake <530040+Steake@users.noreply.github.com>
…ount RPC Co-authored-by: Steake <530040+Steake@users.noreply.github.com>
Co-authored-by: Steake <530040+Steake@users.noreply.github.com>
…n pruning, and RC1 release notes Co-authored-by: Steake <530040+Steake@users.noreply.github.com>
…sk space Co-authored-by: Steake <530040+Steake@users.noreply.github.com>
…ion, logging Key changes: - Merkle gadget: Added comprehensive security documentation for algebraic hash - Admin wallet: Added insecure-tx-signing feature flag for private key endpoint - VRF chaining: Fixed race condition by holding lock during VRF proof generation - Transaction nonce: Added non-zero gas requirement for new accounts (DoS protection) - State logging: Changed to structured logging with full pubkey for debugging Co-authored-by: Steake <530040+Steake@users.noreply.github.com>
Co-authored-by: Steake <530040+Steake@users.noreply.github.com>
… documentation Co-authored-by: Steake <530040+Steake@users.noreply.github.com>
Co-authored-by: Steake <530040+Steake@users.noreply.github.com>
…on-hardened code Co-authored-by: Steake <530040+Steake@users.noreply.github.com>
… in favor of production code Co-authored-by: Steake <530040+Steake@users.noreply.github.com>
…and use MAX_HALVINGS constant Co-authored-by: Steake <530040+Steake@users.noreply.github.com>
Resolved all merge conflicts between rc1 and feature/economic-system-and-rewards branches. The resolution strategy prioritized the feature branch improvements: - Logging: Used tracing instead of println/eprintln for better observability - Transaction indexing: Kept O(1) hash-based transaction lookup - VRF chaining: Kept proper VRF chaining implementation - RPC methods: Retained additional methods (eth_gas_price, eth_get_transaction_count, eth_pending_block_number) - State management: Kept BalanceOverflow error and proper error logging - ZKP circuits: Retained better error handling with Result types and comprehensive tests - Security: Kept robust validation for new accounts with nonce 0 All conflicts resolved in favor of feature/economic-system-and-rewards where it provided better functionality, error handling, and documentation.
This merge brings in all the resolved conflicts between rc1 and feature/economic-system-and-rewards. Resolution prioritized the feature branch improvements including better logging, transaction indexing, enhanced RPC methods, and robust error handling.
…8H7DHxRNV8Pa6Xpmz7hUz Claude/resolve merge conflicts
Co-authored-by: Steake <530040+Steake@users.noreply.github.com>
Co-authored-by: Steake <530040+Steake@users.noreply.github.com>
Merge rc1 into feature/economic-system-and-rewards with security hardening
Owner
Author
|
@copilot
|
10 tasks
Contributor
Co-authored-by: Steake <530040+Steake@users.noreply.github.com>
…d benchmarks Co-authored-by: Steake <530040+Steake@users.noreply.github.com>
Co-authored-by: Steake <530040+Steake@users.noreply.github.com>
Co-authored-by: Steake <530040+Steake@users.noreply.github.com>
Co-authored-by: Steake <530040+Steake@users.noreply.github.com>
…alidation Co-authored-by: Steake <530040+Steake@users.noreply.github.com>
RC1: Add full-stack wallet API with Poseidon hash, hardware wallet, HSM support, and comprehensive documentation
…dize terminology Co-authored-by: Steake <530040+Steake@users.noreply.github.com>
Fix WHITEPAPER_AUDIT.md notation, clarifications, and terminology
Feature/economic system and rewards
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This pull request introduces a full-stack wallet API to the BitCell admin console, enabling users to check balances and send transactions directly from the dashboard. It includes backend API endpoints, configuration updates, and a new frontend wallet section. Additionally, a detailed agent implementation plan for RC1 readiness is added. The most important changes are grouped below:
Wallet API Integration
walletAPI module (crates/bitcell-admin/src/api/wallet.rs) providing endpoints for checking balances and sending transactions via RPC to the node.WalletConfigfor RPC connection settings, with defaults set inConfigManager. [1] [2] [3]/api/wallet.Frontend Dashboard Enhancement
Project Planning and Documentation
AGENT_PLAN.md) detailing a step-by-step roadmap for bringing BitCell to RC1, including wallet, RPC, state persistence, security, networking, and observability tasks.Miscellaneous
ark-snarkdependency toCargo.tomlto support upcoming cryptographic features.These changes collectively enable wallet functionality in the admin console and provide a clear development roadmap for RC1 readiness.